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Introduction 

Assessment  of  foreign  technology  and  its  potential  as  a  threat  to  the 
United  States  and  its  allies  is  often  a  problem  of  anticipating  new 
developments.  Development  of  U.S.  weapon  systems  is  often  driven  by  a 
expected  foreign  threat  as  opposed  to  a  direct  result  of  an  observed  threat. 
For  this  reason,  thorough  analysis  of  potential  system  upgrades  must  be 
performed  by  intelligence  analysts.  An  example  of  such  an  analysis  would 
be  the  new  performance  characteristics  of  a  surveillance  radar  in  response 
to  new  CPUs.  In  a  scenario  such  as  this,  the  software  subsystem  is  fairly 
well  understood  so  the  job  of  the  analyst  is  to  ensure  that  the  software 
ported  to  the  new  computers  will  have  adequate  processing  resources. 

This  report  details  the  analysis  scenario  described  above  by 
assessing  the  CPU  load,  bus  load,  memory  load,  I/O  load,  target  report 
delay  and  probability  of  target  loss  associated  with  the  upgraded  radar. 

System  Architecture 
Physical  Structure 

The  radar  data  system  is  comprised  of  several  components  including 
five  CPUs,  global  and  local  memories,  I/O  handlers,  a  display,  a  modem, 
buses,  and  the  radar  itself.  This  particular  system  is  fictitious,  but  based 
in-part  on  a  U.S.  surveillance  radar. 

The  radar  is  mechanically  scanned  in  azimuth  at  a  rate  of  6  seconds 
per  revolution.  Each  revolution  consists  of  200  segments,  each  of  which 
contains  one  elevation  scan.  An  elevation  scan  results  from  phase  steering 
the  antenna  array  and  has  15  beams  from  0  to  20  degrees  in  elevation. 
From  these  parameters  it  is  easily  seen  that  one  elevation  scan  occurs 
every  0.03  seconds. 

The  system  inter-connectivity  is  shown  in  Figure  1.  The  four 
principle  functions;  Radar  Control,  Target  Processing,  Communications  and 

Display,  are  each  handled  by  a  separate  CPU  which  passes  messages  and 

data  through  the  system.  Each  of  these  computers  and  the  I/O  handlers 
have  their  own  local  memory.  User  control  is  maintained  through  a 
Operator  Interface  (I/F)  which  communicates  directly  with  each  of  the 
other  functions  as  opposed  to  passing  messages  through  global  memory. 

Figure  1  also  shows  the  data  processing  threads  for  this  system.  A 
thread  is  defined  as  the  processing  initiated  by  some  specific  recurring 
event.  The  target  report  thread  is  the  processing  associated  with  the 

handling  of  each  target  detection  report.  This  thread  is  initialized  by  the 

arrival  of  a  target  into  the  First-Come  First-Served  queue  inside  the  signal 
processor  (SP).  If  tne  radar  control  (RC)  function  doesn't  access  target 
reports  from  SP  in  a  timely  fashion,  the  input  queue  will  overflow. 
Queuing  analysis  for  every  queue  in  this  system  must  therefore  be 
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System  Overview 


Operator  control  commands  (green)  may  also  come  from  Modem 


performed  since  it  is  assumed  that  for  cost  and  real  estate'  reasons, 
queues  will  be  kept  at  a  minimally  acceptable  length. 

System  Specifications 

The  required  specifications  for  system  performance  during  both 
nominal  and  peak  scenarios  are  identified  in  Table  1.  These  specs  are 
usually  derived  from  what  opposition  forces  anticipate  facing  in  the  way  of 
U.S.  and  allied  forces.  False  alarms  are  processed  identically  to  actual 
detection  reports,  and  are  made  available  to  the  target  processor  for 
analysis.  If  the  target  processor  does  not  eliminate  the  false  report,  it  is 
then  sent  to  the  display  and  out  the  modem  link.  If  the  original  system 
was  capable  of  eliminating  50%  of  the  false  targets  through  target 
processing,  one  can  therefore  assume  that  same  rate  for  the  new  system 
would  be  appropriate  and  thus  all  analyses  will  assume  200  and  400  false 
alarms  out  of  the  signal  processor  for  nominal  and  peak  loads,  respectively. 


Table  1  -  System  Specifications 


Specification 

Nominal  Load 

Peak  Load 

Comments 

Target  Load 

500 

reports/scan 

False  Alarms 

100 

200 

reports  out/scan 

Display  Request  & 
Operator  Commands 

1 

1 

requests/minute 

Priority  Filters 

2  priority  1  all  else 
priority  0 

2  priority  I  all  else 
priority  0 

defined  by  operator 
chosen  sectors 

Background 

Diagnostics 

once  /  lOscans 

none 

Probability  of 
Target  Report  Loss 

1  % 

I  % 

The  data  system  is 
allowed  to  lose  1  out 
of  100  targets 

CPU  spare 

50  % 

40  % 

measure  by  process 
time  required  to 
complete  one 
elevation  scan 

CPU  Performance  Specifications 

As  mentioned  earlier,  the  basis  for  the  system  upgrade  is  the 
installation  of  new  computers  to  handle  processing  requirements. 
Advances  in  foreign  computing  capability  is  closely  monitored  by  U.S. 
intelligence  organizations.  Whether  the  new  computers  were  developed 
through  foreign  research  and  development  or  by  the  acquisition  of 
Western  technology  is  not  pertinent  to  this  discussion  since  only  fictitious 
CPU  performance  specifications  are  used.  Table  2  contains  the 

performance  criteria  for  the  new  computers. 
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Table  2  -  CPU  performance  specifications 


Processing  Load 

comment 

RC  get  templates  from  GM 

10  msec/template  +  data 
transfer 

as  often  as  1/min 

RC  send  templates  to  SP 

data  transfer 

once  per  elevation  scan 

TP  no  target  load 
background 

100  msec/scan 

evenly  distributed 
throughout  the  scan  (one 
revolution) 

TP  coordinate  estimation 

2.0  msec/report 

converts  elevation  angle 
to  altitude  then  performs 
table  look-up  to  correct  for 
atmospheric  disturbance 

COMM  no  target  load 
background 

150  msec/scan 

evenly  distributed 
throughout  the  scan 

COMM  data  transfer 

cmds  from  Oper  I/F, 
modem  +  rpts  from  target 
table  +  reports  to  display  + 
rpts  out  modem 

Oper  I/F  and  modem 
commands  arrive 
l/minute  maximum 

Radar  Diagnostics 

200  msec/diag  report  in  TP 
+  transfer  from  COMM  to 
display 

Self  diagnostics 

3  seconds  to  complete 

distributed  throughout  10 
scans 

All  other  CPU  performance  specifications  -  RC  handling  of  target 
reports,  TP  data  editing,  TP  table  management,  and  COMM  retrieval  of 
target  reports  will  be  estimated  from  pseudo  code. 


Data  System  Messages 

The  bulk  of  the  processing  load  will  be  due  to  messages  being 
transferred  around  the  system.  Message  transfer  times  are  determined 
from  the  summation  of  the  setup  times  and  the  time  required  to  send  the 
data  over  the  bus.  Data  transmittal  with  this  system  is  quite  simple.  Data 
transmitted  over  the  system  bus  requires  setup  of  500  psec  for  RC,  TP,  GM, 
OIF  and  COMM  and  transfers  at  a  rate  of  200  bytes  per  msec.  This  transfer 
rate  also  applies  to  the  display  subsystem,  however  setup  time  is  700  psec. 
The  modem  also  requires  a  700  psec  setup  time,  but  can  only  transfer  data 
at  a  rate  of  1.2  bytes  per  msec. 

Target  reports  are  10  bytes  long  and  consist  of  a  range,  azimuth, 
elevation,  time,  and  type  for  each  target.  Despite  the  use  of  azimuth 
hashing  1,  azimuth  is  stored  because  azimuth  angles  are  measured  more 
accurately  than  gross  segment  hashing  angles. 


^  the  hashing  function  takes  an  azimuth  and  returns  an  index  into  the  target  table  (0 
-  199). 
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Messages 

Min  Length 
bytes 

Setup  Time 
msec 

Data  Rate 
by  tes/msec 

SP  Detection 
Reoort 

10 

10 

0.3 

500 

Detection 
Report  to  GM 

10 

10 

0.5 

Template  from 
RC  to  SP 

400 

2000 

0.3 

500 

Target  Reports 
to  Display 

25 

35 

0.7 

200 

Target  Reports 
to  Modem 

10 

10 

0.7 

1.2 

Operator 

commands 

5 

5 

0.5 

200 

1200 

1500 

0.7 

200 

Template  from 
GM  to  RC 

400 

2000 

0.5 

200 

Diagnostic 
Reports  to  TP 

100 

250 

0.5 

200 

Diagnostic 
Reports  to 
COMM 

100 

250 

0.5 

200 

Diagnostic 
Reports  to 
Display 

100 

250 

0.7 

200 

System  Analysis 

Target  Distribution  Analysis 

One  implementation  of  an  azimuth  hashing  scheme  partitions  the 
area  of  radar  coverage  into  200  sectors  of  equal  area  as  shown  in  Figure-2; 
therefore  the  probability  that  any  one  target  is  in  any  given  sector  is  0.005 
(1/200).  Furthermore,  the  probability  that  any  n  of  the  1600  (1200  real, 
400  false)  targets  in  the  coverage  area  lie  in  a  given  sector  is  determined 
by  the  binomial  distribution: 


Azimuth 
Segment 
one  of 
200 


Pfn  targets  in  sector)  = 

(  n  )  P"(1-P)N-" 

Which  can  be  estimated  by  the 
Poisson  Distribution  since  N»p. 

M.,  (No)" 

P(n  targets  in  sector)  = 


Flg-2 


Coverage 

Area 


A  family  or  mass  functions,  each  of  which  ii  dependent  upon  the  number 
of  targets  in  coverage,  can  be  used  to  describe  this  system.  Figure  3  shows 
the  function  for  peak,  nominal  and  a  third  load  which  is  representative  of 
the  system  when  the  modem  is  operating  at  85%  capacity.  The  third  curve 
which  corresponds  to  565  targets  in  coverage  will  also  be  used  as  a  means 
for  estimating  CPU  load  and  represents  a  typical  day-to-day  load.  The  565 
targets  were  derived  from: 


sweep  time 
service  time 


200  seg  (0.85)  = 


0.03  sec 


10  bytes 


1200  bytes/sec 


+  0.0007  sec 


(200  seg)  (0.85) 


=  564.57  reports/scan 


Figure  3  -  Azimuth  List  Lengt 


targets/elevation  scan 


Global  Memory  Design 

A  likely  scenario  is  that  target  reports  are  stored  in  global  memory 
by  the  implementation  of  a  circular  buffer.  The  use  of  a  circular  buffer 
would  eliminate  the  need  to  purge  the  table  for  each  scan  by  arranging  the 
memory  so  that  the  scan  for  true  North  always  begins  at  the  same  position 
as  shown  in  Figure  4. 
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Global  Memory 


COMM 
processing 
this  area 

TP  processing 
this  area 


RC  processing 
this  area 


scan  1-1 
scan  I 


scan  1+1 


Fig-4 


Access  to  the  target  data  can  be  controlled  by  the  utilization  of  semaphores 
so  that  RC,  TP  and  COMM  do  not  experience  race  conditions^.  When  the 
antenna  begins  to  scan,  RC  will  set  the  first  semaphore  (Sj)  to  0  to  indicate 
that  it  only  has  access  to  the  area  of  global  memory  designated  for  the  first 
azimuth-elevation  scan.  When  RC  finishes  an  elevation  scan,  it  increments 
the  semaphore,  and,  if  possible,  begins  to  process  the  next  sector.  TP  then 
builds  the  linked  data  structure  (represented  by  Lj  in  Figure-5), 
increments  the  semaphore  and,  if  RC  has  completed,  moves  on  to  the  next 
scan.  The  COMM  processor  then  performs  its  function  and  sets  the 
semaphore  back  to  0. 


synchronization 


^when  two  or  more  processes  are  reading  or  writing  some  shared  data  and  the  final 
result  depends  on  who  runs  precisely  when. 


8 


The  three  processors  sequentially  perform  their  respective  functions 
with  the  targCi  data.  So  long  as  each  processor  can  perform  its  function  in 
less  than  the  time  required  to  perform  one  elevation  scan,  then  all  three 
processors  will  move  in  lock  step.  In  the  event  that  one  of  the  processors 
require  more  than  30  msec  (one  elevation  scan  time)  to  perform  its 
tasking,  then  the  processor  will  lag  (in  terms  of  which  elevation  scan  it  is 
processing)  behind  the  others,  but  will  eventually  catch  up  so  long  as  the 
average  list  length  can  be  handled  within  30  msec.  If  this  is  not  possible, 
the  system  will  lock  up  and  target  data  will  be  lost  until  the  semaphore 
allowing  RC  to  continue  processing  is  set. 

Radar  Control  Processing 

The  primary  function  of  the  Radar  Control  processor  is  moving  target 
detection  reports  from  the  signal  processor  queue  to  the  circular  buffer  in 
global  memory.  RC  accomplishes  this  by  reading  the  reports  from  the  SP 
buffer  to  its  own  local  memory.  RC  first  places  a  pointer  in  the  Aj  location 
which  contains  the  address  of  the  first  report  of  the  elevation  scan  and 
then  sequentially  writes  reports  to  GM.  Before  proceeding  to  the  next 
elevation  scan,  RC  writes  the  number  of  reports,  Nj,  to  global  memory. 
Prior  to  accessing  detection  reports,  this  processor  must  supply  templates 
to  SP  which  it  retrieves  from  global  memory  for  waveforms  and  steering 
angles  for  each  beam  to  the  Signal  Processor.  Other  overhead  functions 
include  the  creation  and  handling  of  diagnostic  reports. 

Pseudo-code  for  Radar  Control  Processing 

Pseudo-code  for  the  three  main  processing  functions  (RC,  TP,  and 
COMM)  are  written  for  purposes  of  estimating  report  handling  execution 
times.  The  format  of  the  pseudo-code  is  akin  to  C  (psuedo-C?).  Comments 
are  used  to  describe  data  transfer  only.  Execution  times  for  all  processors 
are  based  on  2  psec  access  to  GM  and  0.85  psec  access  to  local  memory. 
Each  High  Level  Instruction  takes  4  x  0.85  =  3.4  psec  plus  any  access  time 


to  global  memory. 

pseudo-code 

comment 

execution 
time  (usee) 

IF  0  ==  0) 

3.40 

A,  =  0; 

/*  RC  local  to  GM  */ 

5.40  *  (1/200) 

Next_Azimulh=0; 

r 

3.40  *  (1/200) 

1 

ELSE 

A:  =  Next_Azimulh: 

!*  RC  local  to  GM  */ 

5.40  *  (199/200) 

J 

counter=0; 

3.40 

WHILE  (target  report  in  SP  queue)  { 

!*  SP  local  to  RC  local*/ 

3.40  *  N 

rc.report(counter)  =  sp. report; 

(0.3  + 

10/500)  *  1000  *  N 

counter++: 

) 

FOR(index=l;  index<=counter:  index++) 

3.40  *  N 

/*  RC  local  to  GM*/ 

3.40  *  N 
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/*  RC  local  to  GM  */ 


&gm.report+10  =  rc.reporl(index); 

} 

Nj=counter; 

Next_Azimuth  =  counter*  10; 
j++;  (modulo  200) 
semaphorej  =  1; 


/♦  RC  local  to  GM  */ 


(0.5  +  10/200)  *  1000  ♦  N 

5.40 

3.40 

3.40 

5.40 


880.2*N  +  29.8 

Timing  Requirements 

The  CPU  load  for  the  RC  processor  consist  of  the  summation  of  the 
times  necessary  to  send  the  template  to  SP,  perform  table  management, 
retrieve  templates  from  GM  when  they  have  been  requested  by  the 
operator,  carry  out  background  diagnostics,  and  perform  diagnostic  report 
handling.  Of  these  functions,  only  the  table  management  execution  time 
varies  with  the  number  of  targets  to  be  processed.  Using  the  565  target 
load  as  a  basis,  processing  times  for  RC  and  the  probability  that  each 
particular  processing  time  will  be  required  are  tabulated  in  Table  4. 

send  template  to  SP  =  0.3  +  =  4.3  msec 


table  management  =  0.8802  *  N  +  0.0298  =  time  (msec) 


Although  constant,  the  4.3  msec  required  to  transfer  a  template  to  SP  is 
included  because  this  function,  unlike  operator  requests,  must  be 
performed  for  each  elevation  scan. 


Number  of 
Reports 

1 

1 

P{list 
length  =  N} 

Number  of 
Reports 

Exec,  time 
(msec) 

P{list 
Iength  =  N} 

0 

4.33 

5.94E-02 

8 

11.37 

5.94E-03 

1 

5.21 

1.68E-01 

9 

12.25 

1 .86E-03 

2 

6.09 

2.37E-01 

10 

13.13 

5.26E-04 

3 

6.97 

2.23E-01 

1 1 

14.01 

1.35E-04 

4 

7.85 

1.57E-01 

12 

14.89 

3.18E-05 

5 

8.73 

8.88E-02 

13 

15.77 

6.90E-06 

6 

9.61 

4.18E-02 

14 

16.65 

1.39E-06 

7 

10.49 

1 .68E-02 

15 

17.53 

2.62E-07 

Plotting  this  data  set  shows  that  the  average  processing  time  of  6.81 
msec  will  occur  with  a  probability  of  approximately  0.225. 


^Execution  time  =  tabic  management  +  sending  template  to  SP  (constant  4.3  msec). 
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Figure  6  -  RC  Processing  Tim 


During  peak  load,  the  only  operator  request  that  can  be  issued  to  this 
processor  is  for  a  template  change  (a  request  for  a  diagnostic  report  is  not 
applicable  because  CPU  diagnostics  are  typically  not  performed  during 
peak  load  scenarios);  therefore,  any  remaining  CPU  time  can  be  allocated  to 
this  task.  If  the  processor  is  to  function  with  a  40%  spare  then: 

send  template  to  SP  =  4.3  msec 

table  management  =  880.2  *  8  +  29.8  =  7071.4  psec  =  7.1  msec 

background  diagnostics  =  0.0. 

operator  request  for  diagnostic  report  =  0.0 

remaining  CPU  time  =  (30  *  0.6)  -  (4.3  +  7.1)  =  6.6  msec/seg 

and 

new  template  processing  =  get  operator  request  +  get  template  from  GM 

=  0.525  +  20.525  =  21.025  msec 


If  the  6.6  msec  is  used  to  handle  a  request  for  a  new  template,  then 
the  operator  can  expect  a  response  for  the  new  template  request  within: 


=  95.6  msec  before  new  template  arrives  at  SP 


During  nominal  load  processing,  two  different  operator  requests  can 
be  serviced;  the  request  for  a  new  template  and  a  request  for  a  diagnostic 


report.  These  requests  are  to  be  handled  during  the  remaining  CPU  time 
after  RC  has  performed  its  principle  tasks. 


send  template  to  SP  =  4.3  msec 

table  management  =  880.2  *  3.5  +  29.8  =  3110.5  psec  =  3.1  msec 
background  diagnostics  =  3  seconds  /  10  scans  =  1.5  msec 
Recalling  that  the  processor  operates  at  50%  spare  during  nominal  loading; 
remaining  CPU  time  =  (30  ♦  0.50)  -  (4.3  +  3.1  +  1.5)  =  6.1  msec 

and 

diagnostic  report  processing  =  get  operator  request  +  get  SP's  report  +  send 

both  reports  to  TP 

'(»■=*  200)-^ 

=  0.525  +  0.8  +  3.5  =  4.8  msec 

If  6.1  msec  are  used  to  handle  either  operator  request,  then  the 
expected  response  time  for  each  would  be; 


/  21  025  ^ 

30.0  *  I — — 1  =  103.4  msec  to  send  new  template  to  SP 
diagnostic  reports  can  be  expected  to  leave  RC  during  one  segment  since  4.8  <6.1 

It  is  interesting  to  note  that  if  the  user  specification  with  respect  to  CPU 
spare  is  maintained  with  this  design  which  allows  for  new  templates 
during  peak  activity,  the  templates  will  arrive  at  SP  sooner  during  peak 
conditions. 

With  this  design,  there  are  three  conditions  which  impact  the  CPU 
spare  of  this  processor  (1)  when  operating  at  50%  capacity  and  the  number 
of  targets  become  so  large  that  the  operator  request  for  a  new  template 
cannot  be  handled  within  1  minute,  (2)  when  operating  at  60%  and  the 
number  of  targets  becomes  so  large  that  a  40%  spare  cannot  be  maintained 
and  (3)  number  of  targets  becomes  so  great  that  it  is  not  possible  to  accept 
targets  and  still  get  the  template  over  to  the  SP. 

To  meet  (1)  the  following  condition  must  be  held; 


CPU  spare  > 


1  minute 
2  1 .025  msec 


15  -  (4.3  +  1.5  +  0.8802  *  N  +  0.0298)  >  0.00035  msec  =>  N  <  10.4 

This  calculation  shows  that  even  if  the  average  number  of  targets  is  10.4 
(corresponding  to  2082  targets)  50%  CPU  load  can  be  maintained  on 
average  throughout  the  sweep,  but  there  may  be  conditions  in  one 


elevation  scan  where  this  can't  be  upheld.  As  a  worse  case,  the  probability 
of  more  than  10  targets  in  one  elevation  scan  during  peak  load  is: 
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P(>  10  targets  inside  sector}  =l-SP{j  targets) 

j=0 

=  0.183 

At  above  10  targets,  RC  will  operate  at  40%.  This  spare  can  be  maintained 
as  long  as  the  list  length  is  less  than  14  as  determined  by: 

18  -  (4.3  +  1.5  +  0.8802  *  N  +  0.0298)  >  0.00035  msec  =>  N  ^  13.8 

The  probability  of  this  occurring  is: 


1  3 

P(>  13  targets  inside  sector)  =1-Xf*{j  targets) 

j=0 

=  0.034 


Looking  at  the  extreme  case,  there  may  be  a  problem  with  the  system 
backing  up  if  any  of  the  CPUs  cannot  finish  their  processing  within  one 
elevation  scan  (i.e.,  30  msec).  This  is  particularly  critical  for  the  case  of  RC. 
If  RC  cannot  remove  reports  from  the  SP  queue,  they  will  not  be  processed 
irregardless  of  whether  or  not  TP  and  COMM  whould  have  been  free  to 
handle  them.  It  is  therefore  imperative  that  RC  never  lag.  To  check  this, 
the  maximum  number  of  targets  that  RC  can  handle  in  one  azimuth  sweep 
and  still  send  a  template  to  SP  is  given  by: 

swe.e.p 

service  time 


0.03  seconds  -  0.0043  seconds 
0.0009 1  seconds/target 


X  200  =  5648  targets  <  1600 


If  the  user  ever  wishes  to  change  the  specifications  to  handle  more  targets 
in  coverage,  this  processor  is  capable  of  managing  up  to  5600  reports.  I 
wouldn’t  recommend  that  this  be  done,  but  these  figures  do  provide  a 
ceiling  for  this  processor.  For  the  purpose  of  this  analysis,  it  is  safe  to  say 
that  the  new  computer  is  well  suited  for  RC  since  it  was  shown  that  this 
processor  can  maintain  a  50%  spare  and  still  handle  in  excess  of  2000 
targets. 


Signal  Processor 

As  shown  in  Figure  1,  the  Signal  Processor  lies  between  the  radar 
itself  and  the  Radar  Control  processor.  One  purpose  of  this  processor  is  to 
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receive  target  reports  and  queue  them  up  until  RC  is  ready  to  accept  them. 
The  SP  processor  also  sends  template  data  to  the  radar  at  a  rate  of  one  per 
elevation  scan.  Templates  are  received  from  RC  at  the  same  rate.  This 
arrangement  is  established  because  SP  does  not  typically  have  sufficient 
local  memory  to  store  an  entire  azimuth  scan's  worth  of  template  data.  SP 
also  performs  self  diagnostics  that  must  be  passed  in  a  report  form  to  TP 
through  RC. 

SP  Queue  Analysis 

Although  SP  lies  sequentially  ahead  of  RC  (in  terms  of  report 
handling),  the  expected  service  time  from  RC  analysis  is  needed  to  analyze 
the  SP  queue.  For  the  purpose  of  this  report,  the  assumption  is  made  that 
SP  places  detection  reports  into  the  SP  queue  with  Poisson  arrival 
statistics;  therefore  the  arrival  rate  at  peak  conditions  is  given  by: 


Plk}  = 


where 

X  =(1200  reports/scan  +  400  failures/scan)  5  seconds  ~ 

The  service  time  associated  with  RC,  t,  is  equal  to  the  sum  of  the  transfer 
time  from  SP  to  RC,  the  transfer  time  from  RC  to  GM  and  the  overhead 
associated  with  RC's  handling  of  the  report.  These  three  items  are  all 
inherent  to  the  pseudo-code  execution  time  developed  for  RC;  therefore  the 
service  time  for  1  detection  report  is: 

service  time  =  880.2  *  1  +  29.8  =  910  pscc  =  0.(X)091  seconds 

By  realizing  that  this  system  is  modeled  with  a  constant  service  time,  the 
M/D/1 /n  queue  analysis  method  attached  as  an  annex  to  this  report  can  be 
used  to  determine  a  suitable  queue  size  given  a  desired  probability  of 
overflow  equal  to  0.25%  and  Xt  equal  to  0.24  (267  x  0.00091).  The  steady 
state  vector  below  shows  that  a  queue  size  of  3  will  satisfy  the 
specifications. 

V=  [  7.603  X  lO'l  2.062  x  10-1  3.020  x  10-2  3.061  x  10-3  2.499  x  10-4] 


Target  Processing 

The  Target  Data  Processor  is  responsible  for  three  major  report 
handling  functions;  (1)  weeding  out  duplicate  reports  from  adjacent  beams 


and  reports  that  have  unlikely  parameters'^,  (2)  estimating  target  altitude, 
and  (3)  storing  the  resultant  report  in  a  Global  Memory-based  target  table. 

Processing  begins  by  retrieving  the  first  report  from  this  elevation 
scan  by  using  the  Aj  pointer  left  by  RC.  TP  then  reads  each  of  the  Nj 
reports  into  its  local  memory  and  sorts  them  using  the  insertion  sort 
routine.  This  sort  algorithm  is  a  function  of  as  opposed  to  faster  log(N) 
sort,  but  since  the  linked  list  is  expected  to  be  relatively  short  and  already 
close  to  range  order,  it  is  not  necessary  to  employ  a  more  efficient  sort 
function. 

After  the  reports  have  been  sorted  by  range,  duplicate  reports  are 
eliminated  simply  by  not  linking  in  the  redundant  report  as  opposed  to  the 
more  time  consuming  function  of  deleting  the  report  from  Global  Memory. 
Duplicate  reports  are  identified  by  comparing  the  range  and  elevation  of 
the  current  report  with  that  of  the  previous  one.  If  the  ranges  and 
elevations  are  equivalent  (within  a  reasonable  tolerance),  TP  will  treat  the 
reports  as  redundant.  Estimation  of  target  altitude  is  based  on  elevation 
angle,  correcting  for  atmospheric  effects  by  use  of  a  table  look-up.  This 
table  is  stored  in  global  memory. 

Pseudo-code  for  Target  Processing 

*  Discussion  of  pseudo-coding  practices  are  discussed  in  the  Radar 
Control  processing. 


pseudo-code 


comment 


execution 


temp  =  linkj',  /*  GM  to  TP  local  */ 

linkj  =  azimuthj;  f*  GM  to  GM  */ 

azimuthj  =  &linkj;  /*  GM  to  GM  */ 

FOR  (index  =  1;  index  <=  Nj;  index++)  {  /*  GM  to  TP  local  */ 

/*  GM  to  TP  local  */ 

temp.range(index)  =  gm. report. range(index); 

/*  GM  to  TP  local  */ 

temp.elevation(index)  =  gm. report. elevation(index); 

} 

FOR  (index  =  1;  index  <=  Nj;  index  ++)  /*  GM  to  TP  local  */ 

map(index)  =  index  -1; 
insertion_sort(temp,map,Nj); 

FOR  (index  =  1;  index  <=  Nj;  index++)  {  /*  GM  to  TP  local  */ 

if  (temp.rangc(index)  ==  prev_temp.range(index)  & 

temp.elevation(index)  ==  prcv_tcmp.elevation(index)) 
map(index)  =  -1; 


/*  GM  to  TP  local  */ 


temp_link  =  linkj; 
counter  =  0; 


/*  GM  to  TP  local  */ 


2.0  +  3.40  *  N; 


5.40  *  N; 


2.0  +  3.40  *  N; 


1.7Nj2  +  22.1Nj  -  6.8 
2.0  +  3.40  ♦  Nj 
3.40  *  N; 


'^unlikely  combinations  of  range,  altitude  and  velocity. 


FOR  (index  =  1;  index  <=  Nj;  index++)  {  /*  GM  to  TP  local  */  2.0  +  3.40  *  Nj 

if  (map(index)  >=  0  )  {  3.40  *  Nj 

counler++;  3.40  *  Nj 

/*  TP  local  to  GM  */ 

linkggynfgr  =  tcmp_link  +  10*map(index);  5.40  *  Nj 

} 

} 

Ni=counter;  /*  TP  local  to  GM  *!  5.40 

FOR  (index  =  1;  index  <=  Nj;  index++)  {  /*  GM  to  TP  local  */  2.0  +  .40  *  Nj 

prev_temp.range(index)  =  tenip.range(index);  3.40  *  Nj 

prev_temp.elevation(index)  =  temp.elevation(indcx);  3.40  *  Nj 

1 

semaphorej  =  2;  5.40 

j++;  (modulo  200)  3.40 

} 


1.7Nj2  +  70.3Nj  +  45 


insertion_sort(data,map,N)  { 

FOR  (index  =  1;  index  <=  N;  index++)  { 
temp  =  data(index); 
temp_map  =  map(index); 
counter  =  index; 
while  (data(counter-l)  >  temp)  { 
data(counter)  =  data(counter  -  1); 
map(counter)  =  map(counter  -  1); 
counter--; 

) 

data(counter)  =  temp; 
map(counter)  =  temp_map; 

} 

} 


Timing  Requirements 

The  Target  processing  load  consists  of  table  management,  a  no  target 
load  background,  coordinate  estimation,  background  diagnostics,  and 
servicing  an  operator  request  for  a  diagnostic  report.  As  with  RC,  only 
table  management  time  varies  with  the  number  of  targets  to  be  processed. 
Again,  the  565  target  load  is  used  as  a  basis  for  studying  the  processing 
times  and  their  respective  probability  of  occurrence.  Table  5  and  Figure  7 
show  the  target  table  management  load  as  a  function  of  target  reports. 


3.40  *  (N+2)  +  3.405 

3.40  *  (N-1) 
3.40  *  (N-1) 
3.40  *  (N-1) 
3.40  *  (N-1) 
3.40  *  (N-1)  *  N/86 
3.40  *  (N-1)  *  N/8 

3.40  *  (N-1)  ♦  N/8 

3.40  *  (N-1)  *  N/8 

3.40  *  (N-1) 
3.40  *  (N-1) 

3.40 


1.7N2  +  22.1N  -  6.8 


5 The  N+2  term  is  derived  from  the  fact  that  N  data  values,  the  value  of  N  and  the 
address  of  map  are  placed  on  the  stack. 

^This  loop  is  executed  an  average  of  N/8  times 


Table  5  -  Target  Processing  Times 


Number  of 
Reports 

P{list 
length  =  K} 

Number  of 
Reports 

Exec,  time 
(msec) 

P{Iist 
length  =  K} 

0 

0.045 

5.94E-02 

8 

16.72 

5.94E-03 

1 

2.12 

1.68E-01 

9 

18.82 

1.86E-03 

2 

4.19 

2.37E-01 

10 

20.92 

5.26E-04 

3 

6.27 

2.23E-01 

11 

23.02 

1 .35E-04 

4 

8.35 

1.57E-01 

12 

25.13 

3.18E-05 

5 

10.44 

8.88E-02 

13 

27.25 

6.90E-06 

6 

12.53 

4.18E-02 

14 

29.36 

1.39E-06 

7 

14.62 

1.68E-02 

15 

31.48 

2.62E-07 

Figure  7  -  TP  Processing  Tim 
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During  peak  conditions,  TP  is  not  required  to  process  radar  diagnostic 
reports.  Total  load  during  these  conditions  is  expected  to  be  17.22  msec, 
and  was  determined  by  summing  the  following  times: 

tabic  management  =  1.7(8)^  +  70.3(8)  +  45  =  716.2  ^lsec  =  0.7162  msec 

...  .  100  msec 

no  target  load  background  =  260^50^  ~  msec 


^Execution  time  =  table  management  +  coordinate  estimation 


coordinate  estimation  =  2*N  =  2*8  =  16.0  msec 


background  diagnostics  =  0.0 

Since  operator  requests  are  not  processed  during  peak  conditions,  it  is  only 
necessary  to  determine  if  the  above  processing  time  meets  the  40%  spare 
specification.  The  calculation  below  suggests  that  during  peak  conditions, 
specifications  for  an  average  CPU  spare  can  be  met  and,  although  TP  may 
lag  on  occasion,  the  entire  azimuth  scan  processing  can  be  performed  in 
such  a  way  that  the  radar  will  not  lock  up. 

(0.72  +  0.50  +  16.0  )  <  30.0  ♦  .60  17.22  <  18.0 

During  nominal  load  conditions,  operator  requests  for  diagnostic 
reports  must  be  handled.  Required  processing  times  for  nominal  loads  are; 

table  management  =  1.7(3. 5)^  +  70.3(3.5)  +  45  =  266.8  usee  =  0.27  msec 

...  .  100  msec 

no  target  load  background  =  200  seg  ~ 

coordinate  estimation  =  2  *  N  =  2  *  3.5  =  7.0  msec 


background  diagnostics 


3  sec 
10  scans 


1.5  msec 


Because  the  processor  operates  at  50%  spare  during  nominal  loading; 
remaining  CPU  time  =  (30  *  0.50)  -  (0.27  +  0.5  +  7.0  +  1.5)  =  5.73  msec 

and 

diagnostic  report  processing  =  get  operator  request  +  receive  3  reports  (SP, 

RC,  COMM)  +200  msec  overhead  +  send  composite  report  to 
COMM 

=(0.5  ^  3(0.5  200  +  (0.5 

=  0.525  +  5.25  +  200  +  6.75  =  212.5  msec 


If  5.73  msec  is  used  to  handle  the  operator  request  for  a  diagnostic  report, 
then  the  expected  response  time  to  send  a  composite  report  to  COMM 
(discounting  any  time  spent  waiting  for  the  other  processors  to  send  their 
diagnostic  reports)  would  be: 

30.0(212.5/5.73)  =  1,112.6  msec 

There  are  two  conditions  which  impact  the  CPU  spare  of  this 
processor  (1)  when  operating  at  50%  capacity  and  the  number  of  targets 


become  so  large  that  the  operator  request  for  a  diagnostic  report  cannot  be 
handled  within  1  minute  and  (2)  when  operating  at  60%  and  the  number 
of  targets  become  so  large  that  a  40%  spare  cannot  be  maintained. 

To  meet  (1)  the  following  condition  must  be  held: 


CPU  spare  > 


1  minute 
212.8  msec 


15  -  (0.00I7(N)2  +  0.0703(N)  +  0.045  +  2(N))  >  0.00355  msec 


N<  7.18 


This  calculation  shows  that  above  7  targets,  the  TP  CPU  must  switch  to 
using  40%  spare.  Once  switching  to  an  18  msec  maximum  (i.e,  40%  spare), 
the  CPU  can  handle  up  to: 

0  >  18  -  (0.0017(N)2  +  0.0703(N)  +  0.045  +  2(N))  =>  N  <  8.61 

This  calculation  shows  that  the  CPU  only  operates  above  40%  spare  when 
less  than  9  targets  are  present  in  one  elevation  scan.  Knowing  that  at  peak 
where  the  average  list  length  is  8,  it  is  likely  that  9  or  more  targets  will  be 
present.  Specifically,  this  probability  is: 


8 

P(>  8  targets  inside  sector}  =l-ZP{j  targets) 

j=0 

=  0.407 

The  final  extreme  would  be  when  TP  cannot  perform  its  processing  in  less 
than  100%  utilization.  For  this  to  occur,  the  number  of  targets  in  one 
elevation  scan  would  have  to  be: 

0  >  30  -  (0.0017(N)2  +  0.0703(N)  +  0.045  +  2(N))  =>  N  <  14.3 

Therefore,  if  more  than  14  targets  appear  in  one  elevation  scan  TP  will  lag. 
It  will,  however,  catch  up  before  the  entire  azimuth  scan  is  complete  since 
TP  was  shown  to  be  able  to  handle  an  average  of  8  targets/elevation  scan. 
The  probability  of  TP  not  being  able  to  complete  its  processing  during  a  30 
msec  elevation  scan  during  worse  case  conditions  is: 

14 

P(>  14  targets  inside  sector}  =l-XP{j  targets} 

j=0 

=  0.017  or  1.7% 

Figure  8  shows  the  fully  loaded  TP  processing  times.  When  the  CPU  is 
processing  operator  requests,  it  will  be  pushed  to  the  maximum  CPU  spare 
allowable  by  specification.  After  a  list  length  of  8,  TP  will  operate  at  less 
than  40%  spare. 
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Figure  8  -  Full  TP  processing  loa 


list  length 


Based  on  these  calculations,  the  analyst  can  conclude  that  TP  can 
meet  the  specification  if  the  new  computers  are  used,  but  only  by  a  narrow 
margin. 

Communication  Processing 

The  COMM  processor  is  tasked  with  sending  data  to  the  modem  and 
display.  The  target  data  for  each  elevation  scan  is  read  into  COMM’s  local 
memory  and  immediately  sent  to  the  display  queue.  However,  the  COMM 
modem  processing  is  not  as  simple  because  the  modem  queue  is  apt  to 
back  up  during  greater  than  nominal  conditions.  If  the  target  data  cannot 
be  placed  into  the  modem  queue,  the  report’s  reference  data  (Aj,  Nj  and 
Segment  Number)  is  placed  into  a  backup  array  so  that  COMM  knows 
where  to  find  the  data  when  the  modem  queue  slots  become  available.  If 
data  from  any  segment  is  still  waiting  to  be  sent  to  the  modem  when  that 
segment  comes  around  again,  the  old  data  will  be  lost.  In  other  words, 
data  marked  as  high  priority  must  be  placed  into  the  modem  queue  within 
6  seconds,  or  else  it  will  be  superseded  by  the  updated  scan  data  for  that 
segment. 

Display  Queue  Analysis 

Analyzing  the  display  queue  as  a  worse  case  scenario  (i.e.,  service 
time  is  fixed  a  2  msec),  the  maximum  number  of  targets  that  can  be 
serviced  during  the  0.03  second  elevation  scan  is; 

30  tnsec/scan 

7  =  15  reports/scan 
2  mscc/report 
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With  a  capability  of  servicing  so  many  targets,  it  is  expected  that  the 
queue  will  almost  always  be  empty.  Implementation  of  the  M/D/1 /n 
queue  analysis  verifies  this  as  shown  in  the  results  of  Table  6. 


Table6-Dis£lay^ucuelenMh 


1  Queue 
n  size 

Peak 

load 

Nominal! 
load  1 

1  ^ 

2.4  X  10-3 

5.9  X  10-8  1 

1  ^ 

9.6  X  10-4 

1.2  X  10-14 1 

With  little  or  no  risk  of  overflow  due  to  the  short  service  time,  the 
display  queue  need  only  be  large  enough  to  hold  the  data  upon  receipt; 
thereby,  acting  more  like  a  buffer  than  a  queue.  For  this  reason,  it  is 
suggested  that  a  queue  size  of  1  would  be  used  for  the  new  system. 


Modem  Queue  Analysis 

Based  on  the  provided  specifications,  the  maximum  number  of 
targets  that  can  be  handled  by  the  modem  per  elevation  scan  is  given  by; 


sweep  time 
service  time 


200  seg  = 


0.03  sec 


10  bytes 


1 200  bytes/sec 


+  0.0007  sec 


200  seg  =  664.2  reports/scan 


Seeing  as  though  664  is  less  than  the  specified  1400  peak  load,  one  can 
conclude  that  the  modem  does  not  have  the  bandwidth  to  handle  peak 
conditions  and  a  priority  queuing  system  is  necessary  to  control  the  flow  of 
data  to  the  modem.  The  previous  system  had  two  priority  filters  whose 
azimuth  gates  are  not  allowed  to  overlap;  the  same  assumption  will  be 
made  for  this  analysis.  A  high  priority  tag  is  attached  to  any  target  lying 
within  these  two  azimuth  gates  defined  by  the  two  priority  filters. 

Using  the  queuing  analysis  defined  in  the  appendix,  an  imbedded 
Markov  chain  representing  the  scenario  where  the  modem  removes  three 
reports  per  sweep  time  can  be  constructed.  Obviously,  if  the  average 
number  of  arriving  targets  is  greater  than  3,  then  the  queue  will  always 
overflow.  Therefore,  for  the  purpose  of  design,  the  85%  modem  capacity 
scenario  was  used  as  a  basis  for  determining  the  modem  queue  size.  For 
this  case  X  =  565/200  =  2.82  and  an  overflow  probability  of  no  more  than 
one  half  of  one  percent  were  used  as  input  parameters.  The  M/D/1 /24 
analysis  provided  a  steady  state  vector,  v^,  whose  last  term  was 
approximately  0.0044,  demonstrating  that  a  queue  size  of  24  will  meet  the 
specifications.  The  full  steady  state  vector  can  be  found  in  the  annex. 

The  low  priority  queue  is  effectively  unanalyzable,  but  for  this 
analysis,  its  safe  to  guess  that  the  queue  will  be  made  large  enough  to  hold 
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one  azimuth  sweep's  worth  of  data.  This  should  allow  the  operator  enough 
time  to  respond  to  any  alarms  and  change  the  size  of  his  priority  sectors. 

Pseudo-code  for  Communication  Processing 

The  pseudo-code  below  describes  the  processing  required  by  the 
COMM  CPU.  All  target  reports  for  a  given  elevation  scan  are  read  in  from 
GM  and  then  passed  on  to  the  display  queue.  Then  the  report  priority  is 
checked.  Low  priority  reports  are  placed  into  the  low  priority  queue.  High 
priority  reports  have  their  parameters  (Aj,  Nj,  and  Segment  number) 
entered  into  a  list  of  reports  awaiting  transfer  to  the  high  priority  queue. 
In  the  pseudo-code,  a  high  level  IF  statement  is  used  to  check  for  both 
priority  filters.  For  this  reason,  2*(3.40)  is  used  as  a  execution  time  for 
that  line  of  code.  This  approach  ensures  that  no  low  priority  reports  go 
ahead  of  high  priority  reports  that  had  been  backed  up  or  allow  for  high 
priority  reports  to  be  transferred  non  sequentially  (when  short  high 
priority  reports  go  ahead  on  long  ones  that  had  been  backed  up). 

High  priority  target  processing  consists  of  a  loop  which  sends  as 
many  elevation  scans  worth  of  data  as  possible.  The  loop  stops  whenever 
there  is  not  sufficient  room  in  the  queue  for  the  entire  scan  or  until  there 
are  no  longer  any  backup  reports.  To  keep  track  of  the  backed  up  reports, 
head  and  tail  pointers  are  used  in  conjunction  with  the  array  containing 
the  detection  report  parameters. 

Once  a  segment  has  been  processed,  irregardless  of  whether  or  not  it 
was  transferred  to  the  modem  queue,  its  respective  semaphore  is  set  to  0 
so  that  RC  will  be  able  to  bring  in  data  during  the  next  azimuth  sweep. 
This  will  cause  data  that  is  not  transmitted  to  the  modem  queue  within  6 
seconds  to  be  lost. 

In  this  code,  0.50  is  used  for  an  occurrence  probability  for  deciding 
between  low  or  high  priority  paths.  In  practice  this  will  depend  on  the 
size  of  the  high  priority  azimuth  sectors  as  set  by  the  operator. 

The  COMM  pseudo-code  does  not  do  any  reordering  to  handle  the 
"corner  turning  problem". 


pseudo-code  comment  execution 

time^ 

FOR  (index  =  1;  index  <=  Nj;  index++)  {  /*  GM  to  COMM  local  */  2.0  +  3.40*Nj 

/♦  GM  to  COMM  local  V 

comm.rcport(indcx)  =  gni.rcport(indcx);  (0.5  +  10/500)*  1000*Nj 

1 

FOR  (index  =  1;  index  <=  Nj;  indcx++)  {  /*  GM  to  COMM  local  */  2.0  +  3.40*Nj 


*TotaI  execution  time  based  on  the  probability  of  being  in  high  priority  sector  = 
probability  of  being  in  low  priority  =  0.5. 
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/*  COMM  local  to  Display*/ 

gm.display_q(index)  =  coinm.report(indcx);  (0.7+35/200)*1000*Nj 


IF  (not  in  either  high  priority  sector  )  {  2.0  *  3.40 

/*  GM  to  COMM  local  */  0.5 *(2.0  +  3.40*Nj) 

FOR  (index  =  1;  index  <=  Nj:  index++)  { 

/*  COMM  local  to  Modem*/ 

gm.modem_qO(index)  =  comm.range(indcx)  ;  0.5*(0. 7+10/1. 2)*1000*Nj 

} 


ELSE  /*  high  priority  */ 
IF  (backup. seg(tail)  =  j); 
tail++; 

backup. az(head)  =  Aj; 
backup. n(head)=  Nj; 
backup. seg(head)=  j; 
head++; 


/*  GM  to  COMM  local  */ 
/*  GM  to  COMM  local  */ 
/*  COMM  to  COMM  */ 

/*  GM  to  COMM  local  */ 


DO  WHILE  (head  <>  tail) 

IF  (backup. n(tail)  <  number  in  modem  queue)  { 


0.5*3.40 

0.5*3.40 

0.5*5.40 

0.5*5.40 

0.5*3.40 

0.5*3.40 

0.5*5.40 

0.5*3.40 


/*  GM  to  COMM  local  */  0.5*(2.0  +  3.40*Nj) 

FOR  (index  =  1;  index  <=  backup.n(tail);  index++) 

/*  COMM  local  to  Modem*/ 

gm.modem_ql  (index)  =  comm.rangc(index);  0. 5*(0. 7+10/1 .2)*1000*Nj 


tail++; 


0.5*3.40 


ELSE  break; 


semaphorej=0; 
j++;  (modulo  200) 


/*  COMM  to  GM  */ 


10439Nj  +  40.6 


Timing  Requirements 

CPU  load  for  this  processor  is  made  up  of  target  tabic 
target  load  background,  background  diagnostics  and  operator  requests  for 
a  change  in  the  high  priority  azimuth  sectors.  Diagnostic  processing  for 
this  CPU  not  only  consists  of  self  diagnostics,  but  also  the  receipt  of  the 
consolidated  report  from  TP  for  transfer  to  Display.  As  is  the  case  with  the 
other  CPUs,  the  variable  load  time  is  associated  with  the  target  report 
thread.  Table  7  shows  the  execution  time  as  a  function  of  the  number  of 
targets  and  is  calculated  by: 

target  report  proces.sing  =  10439(N)  +  40.6  (psec) 
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Table  7  -  COMM  report  processing  lime 


Number  of 
Reports 

■lumH 

P{list 
length  =  N} 

Number  of 
Reports 

■liiRISH 

0 

0.0406 

5.94E-02 

8 

83.51 

5.94E-03 

1 

10.44 

1 .68E-01 

9 

93.95 

1.86E-03 

2 

20.88 

2.37E-01 

10 

104.39 

5.26E-04 

3 

31.32 

2.23E-01 

1 1 

114.83 

1 .35E-04 

4 

41.76 

1  .57E-01 

12 

125.27 

3.18E-05 

5 

52.20 

8.88E-02 

13 

135.71 

6.90E-06 

6 

62.63 

4.1  8E-02 

14 

146.15 

1 .39E-06 

7 

73.07 

1 .68E-02 

15 

156.59 

2.62E-07 

Figure  9  -  COMM  processing  tim 
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Figure  9  shows  that  even  with  ihc  565  target  load,  a  40%  spare  (on 
average)  cannot  be  realized  for  this  CPU.  To  maintain  the  40% 
specification,  a  mean  list  length  of  1.72  (344  targets)  must  be  achieved. 

18  -  (I0.44N  +  0.0406)  =  0  =>  N=1.72  60%  utilization 

30  -  (10.44N  +  0.0406)  =  0  =>  N  =  2.87  100%  utilization 

Further  more,  with  average  of  only  2.87  reports  per  elevation  scan  (574 
targets  in  coverage),  the  COMM  CPU  will  not  be  able  to  keep  pace  with  the 
radar  and  high  priority  reports  will  be  lost.  These  figures  show  that  COMM 
is  capable  of  handling  the  85%  modem  capacity  case  were  565  targets  are 
expected  to  be  in  coverage,  but  cannot  do  this  and  maintain  the  specified 


2  4 


50%  spare.  Given  this  condition,  we  will  forgo  the  specifications  on 
allowable  CPU  spare  and  determine  expected  response  times  to  operator 
requests.  Later  in  the  report,  a  proposed  solution  to  speeding  up  COMM 
will  be  addressed. 

The  probability  of  either  a  less  than  40%  spare  or  0%  spare  for  this 
processor  under  peak  conditions  are  alarmingly  high. 


1 

P(>  1  targets  inside  sector)  =l-LP(j  targets) 

j=0 

=  0.993 


2 

P(>  2  targets  inside  sector)  =l-ZP{j  targets) 

j=0 
=  0.904 

These  numbers  show  that  the  system  operator  must  keep  tight  controls  on 
this  priority  filters  so  that  the  number  of  reports  sent  to  the  modem  is 
kept  below  an  allowable  threshold,  say  300  to  400  reports. 

During  nominal  load  conditions,  operator  requests  for  diagnostic 
reports  and  requests  for  new  azimuth  gates  are  processed  Required 
processing  times  for  the  344  target  load  are: 


report  processing  =  18.00  msec 


no  target  load  background  = 


1 50  msec 
200  seg 


=  0.75  msec 


background  diagnostics 


3  sec 
10  scans 


1.5  msec 


For  COMM,  it  is  now  assumed  that  a  25%  spare  is  acceptable  for  nominal 
processing. 

remaining  CPU  time  =  (30  *  0.75)  -  (18.00  +  0.75  +  1.5)  =  2.25  msec 

and 

diagnostic  report  processing  =  get  operator  request  +  send  report  to  TP  + 

receive  5  reports  from  TP  +  send  5  reports  to  Display 

fn  <  fn  <  fn  <  5*250>>  _  5*250\ 

-(^0.5  +  20oj‘^(®-^  ■^20oj'^[^-^  200  200  j 

=  0.525  +  1.75  +  6.75  +  6.75  =  15.775  msec 


If  2.13  msec  is  used  to  handle  the  operator  request  for  a  diagnostic  report, 
then  the  expected  response  time  to  send  a  composite  report  to  Display 
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(discounting  any  time  spent  waiting  for  the  reports  to  arrive  from  TP) 
would  be: 


The  processing  load  incurred  as  a  result  of  a  request  to  change  a  filter 
would  consist  of  approximately  5  operator  commands  (1  request  to  change 
filter  and  min  and  max  azimuth  for  each  of  two  filters)  plus  a  nominal 
overhead  time  (e.g.,  0.7  msec).  This  total  time  would  be  5(0.525)  +  0.7  = 
3.325  msec  and  can  therefore  expect  to  be  accomplished  within  two 
elevation  scans. 

Timing  analysis  of  this  processor  has  shown  that  when  the  average 
list  length  is  greater  than  3.5,  then  COMM  will  not  be  able  to  perform  its 
job  within  a  6  second  azimuth  scan.  In  these  cases,  the  semaphores 
allowing  RC  to  bring  in  new  data  will  not  have  been  reset  and  entire  scans 
will  be  lost.  One  possible  solution  to  assume  that  the  new  system  would 
contain  a  software  restructuring  for  the  COMM  processing,  so  that  Low 
Priority  targets  are  not  sent  to  a  low  priority  queue  (a  time  consuming 
function),  but  instead  have  their  address  and  list  lengths  stored  similar  to 
the  way  that  high  priority  targets  are  backed  up.  This  may  reduce  the  risk 
of  loosing  some  high  priority  data  prior  to  the  operator’s  changing  of  the 
azimuth  gates,  but  would  eventually  lead  to  similar  execution  times  after 
the  change  has  gone  into  effect.  (additional  overhead  to  handle  high 
priority  targets  vis  a  vis  low  priority  is  negligible). 

A  more  likely  change  that  would  have  a  great  impact  of  execution 
time  would  be  the  utilization  of  a  new  modem  with  an  expanded 
bandwidth.  If  a  9600  baud  machine  were  used  in  place  of  the  specified 
1200,  execution  time  would  now  be  defined  by: 

3146.9  (N)  +  40.6 

Figure  10  shows  the  COMM  execution  time  with  the  new  modem  vs  that  of 
the  specified  1200  baud.  The  response  of  this  new  design  on  the  order  of 
the  8.91  msec  average  associated  with  the  RC  processor.  Analysis  of  this 
subsystem  indicates  that  the  upgraded  radar  system  must  also  be 
equipped  with  a  more  functional  modem. 
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Figure  10  •  COMM  with  9600  baud  vs  1200  baud 
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Bus  Loading 

The  data  transfer  time  is  due  to  activity  on  each  of  the  buses  must  be 
held  under  30.0  msec  per  elevation  scan.  Each  processor  is  individually 
addressed  to  examine  the  amount  of  time  required  to  put  data  onto  each  of 
the  two  system  buses. 

Calculations  are  made  using  the  85%  modem  load  (i.e.,  N=2.82 
targets/elevation  scan)  except  for  calculations  involving  the  COMM 
processor  where  the  344  target  load  was  used  (N=1.72)  since  this  was 
shown  to  be  a  suitable  load  to  handle  the  restricted  bandwidth  associated 
with  the  modem. 

BUS  1 

from  RC  =  template  to  SP 
^  2000\ 

=  10.3  +  1  =  4.3  msec/elevation  scan 

from  SP  =  target  reports  to  RC  +  diagnostic  report  to  RC 

=  0.9  +  0.8  msec/elevation  scan 
total  load  on  BUSl/clcvation  .scan  =  4.3  +  0.9  +  0.8  =  6.00  msec 
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BUS  2 

from  GM  =  template  to  RC  +  target  data  to  TP  +  target  reports  to  COMM 

0,054)  N.  ((0.5.  ^).n) 


0.5  +- 


=  0.29  +  0.03  +  1.55  =  1.87  msec/elevation  scan 
from  RC  =  target  reports  to  GM  +  2  diagnostic  reports  to  TP 

=1.55  +  3.5  =  5.05  msec/elevation  scan 


from  TP  =  diagnostic  reports  to  COMM 

^0.18  msec/seg^^^ 

n  c  5*250 
0.5  + 


=  0.03  msec/clevation  scan 


from  COMM  =  diagnostic  report  to  TP  +  consolidated  diag.  report  to  DISPLAY  + 
target  reports  to  DISPLAY  +  target  reports  to  MODEM 

'  V  f  >  ((o-^  ^  -  N  ).  ((0.7  .  1^)  .  N 

,  "^  200  J  i  200  J 


=  0.14  +  0.14  +  1.51  +  15.54  =  17.33  mscc/elevation  scan 

from  OIF  =  3*diagnostic  cmmds  +  template  change  cmd  +  change  priority  filter 
emmd  +  display  emmd  +  diagnostic  report 


=  4.20  +  1.75  =  5.95  msec 


total  load  on  BUS2/elcvation  scan  =  1.87  +  5.05  +  0.03  +  17.33  +  5.95  =  30.23  msec 


^recalling  that  6.1  msec  per  elevation  scan  is  used  to  process  the  request  for  a  new 

template;  3.27  is  the  proportional  amount  of  that  6.1  msec  used  for  accessing  the 

global  memory. 

^^during  nominal  operation  5.73  msec  per  scan  is  available  for  TP  to  process  operator 

requests;  0.18  msec  is  the  proportional  amount  of  that  5.73  used  for  sending  out  the 

composite  diagnostic  report. 

during  a  344  target  load  (25%  spare)  2.25  msec  per  scan  is  available  for  COMM  to 
process  operator  requests;  0.25  msec  is  the  proportional  amount  of  that  2.25  used  for 
sending  out  the  diagnostic  report  to  TP 

'^during  a  344  target  load  (25%  spare)  2.25  msec  per  scan  is  available  for  COMM  to 
process  operator  requests;  0.99  msec  is  the  proportional  amount  of  that  2.25  used  for 
sending  out  the  composite  diagnostic  report  to  the  display. 
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The  total  load  on  BUS2  is  dangerously  close  to  the  30  msec  scan  time,  but 
these  calculation  were  made  with  all  operator  request  going  on  at  one  time. 
In  practice,  only  one  request  will  be  on  going  at  one  time,  the  most  timely 
of  which  is  the  request  for  diagnostic  reports.  With  the  other  commands 
removed,  the  total  bus  load  is  27.32  msec. 


1.  CPU  loads  for  each  computer  under  nominal  and  peak  target  loads. 

Detailed  discussions  of  CPU  timing  and  load  requirements  are 
addressed  as  each  CPU  is  addressed  above.  These  findings  are 
summarized  below; 


Table  8  -  Summary  6f  CPU  loads 


Radar  Control  Target  Processin 


Nominal  Exec, 
Time  (msec) 


Nominal  Exec 
Time  w/Operator 
Requests 


50%  spare  met 
(for  average 
list  length) 


Peak  Exec.  Time 
w/Operator 
Requests 


85%  Modem  Exec. 
Time  (msec) 


85%  Modem  Exec 
Time  w/Operator 
Requests 


II 


Communication 


36.6  cannot 
handle 


cannot  service 
requests 


cannot  service 
requests 


2.  The  expected  delay  experienced  for  targets  measured  from  insertion  in 
the  signal  processor  queue  to  transmission  over  the  modem  lines,  using 
the  85%  modem  load  would  be: 


^P  Queue  Wait  Time  +  RC  +  TP  +  COMM  +  Modem  Queue  Wail  Time  = 


0.36  +  6.81  +  5.90  +  29.48  +  10.7  =  53.25  msec 


3.  The  probability  of  discarding  one  or  more  targets  from  a  single  beam. 


By  specification,  a  maximum  of  eight  targets  can  be  recorded  for  each 
beam,  therefore  the  probability  of  discarding  one  or  more  is  found  by 
Poisson  approximation  with  N  =  number  of  targets  in  coverages 
including  false  targets  p  is: 


P  =  .  1  =  3.33  X  10"' 

^  200  segments  J  y  5  beams  j 


P(>  8  targets  inside  sector)  =l-ZP{j  targets) 

j=0 


5: 


=  1- e 
j=0 

=  5.93  X  10-9 


.-0.533 


J! 


•0.233  (2.213^2 


j=0 

near  zero 


J! 


=  e-0.188  85%  modem  capacity 

j=0  J- 

=  near  zero 


4.  Queue  sizes,  for  each  of  the  data  system  queues,  which  is  just  adequate 
to  meet  the  data  system  probability  of  loss  specification. 


Table  9  -  Summary  of  Queue  Analysis 


Signal  Processing 
Queue 

Display 

Queue 

Modem 

Queue 

Length 

3 

1 

24 

P  (overflow) 

0.0022 

0.00094 

0.0044 

Specification 
Designed  for 

Peak  Load 

Peak  Load 

85%  modem 
capacity 

Final  Thoughts 


Detailed  systems  analysis,  in  excess  of  what  has  been  presented  here, 
must  be  performed  in  order  to  maintain  the  highest  attainable  level  of 
knowledge  concerning  current  and,  in  this  case,  projected  foreign 
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aerospace  technology  trends  and  capabilities.  In  addition  to  supporting 
research  and  development,  these  analyses  allow  for  the  assessment  of 
performance  capabilities,  limitations,  and  vulnerabilities  of  current  and 
future  foreign  weapon  systems  thereby  precluding  technological  surprise 
to  the  United  States  and  its  allies. 

In  addition  to  analysis  of  an  individual  system,  this  type  of  work  has 
application  to  large  scale  military  engagement  models.  The  U.S.  Air  Force 
is  active  in  the  use  of  software  modeling  and  simulation  techniques  for 
purpose  of  wargaming.  An  example  of  this  is  a  software  tool  called  the 
Strategic  Penetration  Model  (STRAPEM)  developed  by  the  Boeing 
Corporation.  The  STRAPEM  code  simulates  the  penetration  of  several 
hundred  bomber  aircraft,  their  accompanying  escorts  as  well  as  any  enemy 
interceptor  aircraft  they  may  enter  the  engagement.  Queue  size  and 
probability  of  target  loss  analysis  of  the  type  provided  in  this  report  can 
be  employed  to  control  the  dimensioning  of  data  structures  used  in 
conjunction  with  the  module  responsible  for  modeling  the  radar. 
Application  of  these  ideas  will  be  addressed  in  future  work. 


Addendum 

M/D/1/n  Queue  Analysis 


The  process  necessary  for  determining  a  required  queue  size  for  an 
M/D/l/n^^  queue  follows  directly  from  the  M/D/1  analysis  presented  by 
Trivedi^*^  where  an  infinitely  dimensional  transition  probability  matrix  is 
identified  because  the  incoming  job  queue  is  infinite.  For  the  M/D/1 /3 
case  (represented  by  the  Markov  chain  in  figure  A-1),  the  P  matrix 
contains  a  right-most  column  which  pulls  together  into  one  sink  the 
infinitely  long  rows  defined  by  Trivedi.  It  is  from  this  example  that 
M/D/l/n  queues  are  discussed. 


(Fig  A-1) 
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VT=  V^P 


Voao+Viao=Vo 

Voai-^Viai+V2ao=Vi 

voa2+Vja2+V2ai-hV3ao+Vovao=V2 

Voa3-Hv,a3-HV2a2+V3a]-HVovai=V3 
Vob4+v  ,b4-hV2b3+V3b2+v^^b2=v^^ 


(eq.  A-1) 


aj  =  prob{j  items  arrive  for  service  in  (tj^,  tj^  -b  T^)) 
and 


=  e 


-m 

if 


k- 1 

b|^  =  prob{k  or  more  items  arrive  for  service  in  (tj^,  tj^  -t-  T^)}  =  l-^aj. 

j=0 

T  T* 

In  addition  to  the  n-f-1  equations  generated  by  V*=V  P,  the  equation 
^  Vj  =  ]  must  also  hold  since  the  system  must  only  be  in  one  of  the  n-f-1 
possible  system  states.  It  would  now  appear  that  we  have  a  situation 


'^This  standard  naming  convention  refers  to  a  queue  whose  arrivals  arc 
exponentially  distributed  (M),  constant  service  time  (D),  one  server  (1)  and  a  queue 
length  of  n. 

'‘^Trivedi.  Kishor  Shridharbhai,  Probability  and  Statistics  with  Reliability,  Queuing, 
and  Computer  Science  Applications,  p. 336-341. 
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where  we  are  required  to  solve  n+2  equations  against  n+1  unknowns  (i.e., 
Vq  thru  Vg);  thus,  indicating  that  one  of  these  equations  has  been 
represented  as  a  combination  of  another.  This  is  the  case  and  is  easily 
identified  by  the  fact  that  the  first  two  rows  of  P  are  identical.  This  can 
also  be  realized  by  noticing  that  the  determinate  of  the  P  matrix  is  equal  to 
0.  We  can  now  arbitrarily  remove  one  of  these  equations  and  choose  to 
eliminate  the  first  (^QaQ  +  v  j aQ=VQ).  If  all  of  the  equations  in  (eq.  A-1) 
above  are  rearranged  by  setting  them  equal  to  0. 

VQaj+Vjaj+V2aQ=Vj  =>  VQaj+Vj(a,-l)+V2aQ=0 

The  full  set  of  n+1  equations  can  now  be  represented  by  the  matrix 
equation  RV  =  S  where  R,  V,  and  S  are  the  matrices  shown. 
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Solving  for  V  by  V  =  R'^S  would  provide  a  set  of  steady  state  probabilities 
which  represent  the  likelihood  that  the  system  would  be  in  any  particular 
state  as  time  becomes  infinitely  large.  Of  particular  interest  in  this  case  is 
V4  which  represents  the  probability  that  the  system  has  been  overflowed. 

For  the  purpose  of  this  project,  as  is  typically  the  scenario  in  system 
design,  the  queue  size  is  not  pre-determined  (instead,  a  specification  of 
probability  of  overflow  is  given)  and  is  therefore  left  as  a  design 
consideration  for  the  engineer.  To  perform  this  analysis,  the  general  case 
where  P,  R  shown  below  are  created  until  a  value  for  n  is  found  that  meets 
the  given  overflow  specification  so  that  v^^  is  less  than  or  equal  to  the 

specified  allowable  overflow.  Once  this  has  been  achieved,  the  required 
queue  she  is  n-1  which  is  represented  by  the  saturated  state,  j 
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The  COMM  Modem  Queue  and  COMM  Display  Queue  analysis  is  a 
slightly  different  to  the  SP  queue  analysis  defined  above.  In  the  case  of 
the  COMM  queues,  a  predefined  number  of  reports  will  be  handled  before 
the  COMM  processor  looks  at  the  queue  again.  As  described  before,  for  the 
Modem  queue,  3  reports  will  be  handled  before  COMM  sends  more  data 
and  for  the  display  it  is  15. 

For  the  purpose  of  describing  the  behavior  of  this  queuing  analysis, 
the  imbedded  Markov  chain  in  Figure  A-2  will  be  used.  In  this  system  as 
many  as  three  reports  can  be  handled  by  the  receiving  system  (much  like 
the  modem)  before  new  arrivals  occur.  It  should  be  noted  that  this 
example  implements  a  queue  size  of  3. 


b 


The  stochastic  matrix,  P,  can  be  taken  directly  from  this 
aj  and  bj  defined  as  before. 


PH 
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graph  with 


r  VQ(aQ+aj+a2+a3)+v,(aQ+a^+a2)+V2(ao+ap+V3ao+VQ^aQ=VQ 


Voa4+Vja3+V2a2+V3ai+Vovai=vi 

Voa5+v,a4+V2a3+V3a2+Vova2=V2 

Voa6+v,a5+V2a4+V3a3+Vova3=V3 

Vob7+Vib6+V2b5+V3b4+Vovb4=Vov 


(cq.  A-2) 


Again,  ^Vj=l  and  one  of  the  equations  from  eq.  A-2  can  be  removed.  Since 
the  equation  to  be  dropped  is  arbitrary,  the  first  equation  (vQ(aQ-^aJ-^a2+a3)  -t- 
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V j(aQ+aj+a2)  +  v2(aQ+aj)  +  v^aQ  +  VjjyaQ=VQ)  being  the  most  complicated  would 
be  the  obvious  choice.  This  results  in  an  R  matrix  with  the  form: 
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As  opposed  to  developing  a  general  form  of  R  and  P  for  this  type  of  queue 
analysis,  it  should  be  observed  that  the  SP  queue  is  actually  a  special  case 
of  the  COMM  queues  where  the  number  guaranteed  to  be  serviced  before 
another  arrival  is  0.  A  more  general  form  of  P  for  queue  analysis  where  ’g’ 
is  the  number  that  can  be  taken  from  the  queue  before  new  data  arrives 
and  n  is  the  queue  size,  is: 
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P  and  R  have  dimension  (n+1)  x  (n+1)  where  n  is  the  queue  size 

Some  points  that  may  not  be  immediately  obvious  by  observing  the 
general  form  of  P  is  that  the  summations  in  the  first  column  is  continued 
until  G-I=0.  Also  there  are  a  set  of  duplicate  rows  at  the  bottom  of  the 
matrix  [0,0,.  .  -.a  i,a  ,b  , ]  (as  is  the  case  for  the  bottom  two  rows  of  the 
stochastic  matrix  for  the  COMM  queues). 
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The  M/D/l/n  program  used  to  perform  this  analysis  takes  advantage 
of  this  general  format.  The  code  was  written  in  LightSpeed  C  for  the 
Macintosh.  Information  on  the  code  can  be  attained  from  the  author. 

The  code  was  not  intended  for  operational  use  and  therefore  user 
interface  coding  received  minimal  attention.  The  three  input  parameters 
queue  length,  Xt,  and  number  of  items  guaranteed  to  be  serviced  before 
new  entries  arrive  -  are  issued  as  #DEFINE  statement  entries  at  the 
beginning  of  the  code;  therefore  it  is  necessary  to  edit  and  recompile  the 
code  for  each  run. 
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M/D/1/n  Program  Output 

Signal  Processor  (SP)  Queue  under  peak  conditions 


Steady  State  analysis  for  M/D/1/3  queue 
lambda  t  =  0.240 
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Modem  Queue  for  a  9600  baud  modem  at  peak  conditions 

Steady  State  analysis  for  M/D/1/5  queue 
lambda  t  =  7.000 

up  to  10  items  can  be  serviced  prior  to  new  arrivals 
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the  steady  state  vector  S 
8.755e-001 
5.213e-002 
3.257e-002 
1.903e-002 
1.046e-002 
5.439e-003 

4.914e-003  probability  of  overflow 


Display  Queue  at  peak  conditions 

Steady  State  analysis  for  M/D/1/1  queue 
lambda  t  =  7.000 

up  to  15  items  can  be  serviced  prior  to  new  arrivals 

the  stochastic  matrix  P 
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9.94e-001  3.31e-003  2.41e-003 

9.94e-001  3.31e-003  2.41c-003 

the  matrix  R 

1.4e-003  -l.Oe+000  3.3c-003 

9.6e-004  2.4e-003  -l.Oe+000 

l.Oe+000  l.Oe+000  l.Oe+000 

the  steady  state  vector  S 
9.976e-001 
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MISSION 

OF 

ROME  LABORATORY 

Rome  Laboratory  plans  and  executes  an  interdisciplinary  program  in  re¬ 
search,  development,  test,  and  technology  transition  in  support  of  Air 

O 

Force  Command,  Control,  Communications  and  Intelligence  (C  l)  activities 
for  all  Air  Force  platforms.  It  also  executes  selected  acquisition  programs 
in  several  areas  of  expertise.  Technical  and  engineering  support  within 
areas  of  competence  is  provided  to  ESD  Program  Offices  (POs)  and  other 
ESD  elements  to  perform  effective  acquisition  of  C^I  systems.  In  addition, 
Rome  Laboratory's  technology  supports  other  AFSC  Product  Divisions,  the 
Air  Force  user  community,  and  other  DOD  and  non-DOD  agencies.  Rome 
Laboratory  maintains  technical  competence  and  research  programs  in  areas 
including,  but  not  limited  to,  communications,  command  and  control,  battle 
management,  intelligence  information  processing,  computational  sciences 
and  software  producibility,  wide  area  surveillance/sensors,  signal  proces¬ 
sing,  solid  state  sciences,  photonics,  electromagnetic  technology,  super¬ 
conductivity,  and  electronic  reliability/maintainability  and  testability. 


